Atari Gold/Atari Gold.iso/e_backup/eb_1_54/chk_ofls/chk_ofls.anl

Text File | 1993-10-09 | 9.4 KB | 202 lines

CHK_OFLS: Ein Datenschutz für GEMDOS-umgehende Programme
========================================================

Version 1.03
                                          von Hans-Jürgen Richstein
                                          (c) 1991/92 KAKTUS GbR


Für Programme, die unter Umgehung des Atari-Dateisystems GEMDOS auf
Massenspeicher zugreifen (Diskmonitore, Schnellkopierer etc.) entsteht ein
grundsätzliches Problem: Wenn auf dem angesprochenen Laufwerk zuvor
Dateien vom GEMDOS geöffnet waren oder sich die beiden Parteien während des
Betriebes in die Quere kommen, kommt es fast unweigerlich zu
Datenverlusten. Beide sind darauf angewiesen, das Dateisystem zur gleichen
Zeit für sich alleine zu nutzen. Leider gab es bislang keinen legalen Weg,
beide zu friedlicher Koexistenz zu bewegen.

Das Programm 'CHK_OFLS.PRG' (CHecK Open FiLeS) soll hier in Zukunft Abhilfe
schaffen. Es entstand im Rahmen der Weiterentwicklung des KOBOLD-
Hochleistungsdateikopierers und wird einfach in den AUTO-Ordner kopiert.
Fortan wird z.B. der KOBOLD (ab Version 1.07) nur noch auf solchen
Laufwerken seinen Dienst verrichten, auf denen zu diesem Zeitpunkt keine
Dateien geöffnet sind und verloren gehen könnten. (Sie können ihn dann nach
wie vor auf diesem Laufwerk im GEMDOS-Modus benutzen!), und umgekehrt läßt
das GEMDOS seine 'Finger' von solchen Partitionen, auf denen z.B. der
KOBOLD gerade unter Umgehung des GEMDOS pfeilschnell kopiert.

Weiterhin wird ab dieser Version (V 1.02) das neue sog. XHDI-Protokoll
genutzt, um Wechselplatten zu verriegeln, solange Dateien auf mindestens
einer Partition des eingelegten Mediums geöffnet sind. Dies verhindert
Datenverluste nach ungewolltem Auswurf der Wechselplatte und macht den
Einsatz von CHK_OFLS auch dann sinnvoll, wenn man ansonsten kein
ausdrücklich damit zusammenarbeitendes Programm nutzt.

Damit diese Funktion wirksam wird, benötigen Sie einen XHDI-fähigen
Festplattentreiber, z.B. entsprechend neue Versionen des HUSHI, Diskus,
CBHD usw.

Wenn Sie MultiTos oder MiNT ab der Version 0.94 einsetzen, hat die
Nutzung von CHK_OFLS keinen Sinn, da hier die Vergabe von Dateizeigern
anders funktioniert. Damit es nicht zu überflüssigen Blockierungen von
Laufwerken kommt, sollten Sie es hier nicht einsetzen. Es wird auch nicht
benötigt, da unter diesen Betriebssystemen Funktionen zum Verriegeln von
Laufwerken bereits vorhanden sind.

Die Version 1.03 enthält nun ein 'Workaraound' um eine Eigenheit der
Flexdisk, weswegen diese nicht zusammen mit der V 1.02 funktionierte.

Dieses Programm kann in dem Ordner CHK_OFLS mit den darin enthaltenen und
unveränderten Dateien...

   CHK_OFLS.PRG
   CHK_OFLS.ANL
   OFLSSHOW.ACC
   OPN_FILE.ACC

...beliebig weitergegeben werden und insbesondere auch kostenlos in
dieser Form beliebigen kommerziellen Produkten beigelegt werden. Weiter
unten erfolgt eine genaue Beschreibung der von einem GEMDOS-umgehenden
Programm zu unternehmenden Schritte, um mit CHK_OFLS zu kooperieren. Wenn
Sie also selbst ein Tool schreiben, daß über das BIOS (oder auf noch
niedrigerer Ebene) auf einen Massenspeicher zugreift, dann bauen Sie
einfach die unten beschriebene Unterstützung ein und legen Sie diesen
Ordner dazu.


************************************************************************


CHK_OFLS: Hinweise für Programmierer
====================================

CHK_OFLS hängt sich bei der Installation in den GEMDOS- und den BIOS-
Trap. Es zählt die geöffneten Dateien und protokolliert, wann sie über
Fclose() freiwillig oder per Pterm(), Pterm0(), Ptermres() oder nach einem
echten oder erzwungenen Medienwechsel zwangsweise wieder geschlossen
werden. Über einen 'Cookie' namens 'OFLS' kann Ihr Programm die Existenz
von CHK_OFLS ermitteln und erhält als Cookie-Value eine Zeiger auf folgende
Struktur (hier in C):

   struct ofls_cookie
   {
      long  product;             /* 'OFLS' (0x4F464C53)    */
      unsigned short version;    /* z.B. 0x0103 für V 1.03 */
      signed short drives[32];   /* Infos für 32 Laufwerke */
      signed short reserved[32]; /* Für evt. Erweiterungen */
   };

Nach den vier Buchstaben 'OFLS' folgt also eine Versionsnummer und dann die
entscheidenden 32 Bytepaare, in denen für jedes Laufwerk (drives[0] = A:
etc...) die Anzahl der zu diesem Zeitpunkt darauf geöffneten Dateien
ausgelesen werden kann. Solange hier also eine 0 steht, können Sie
bedenkenlos über das BIOS an dieses Laufwerk herangehen.

Um nun während Ihrer Zugriffe zu verhindern, daß das GEMDOS auf dieses
Laufwerk zugreift, schreiben Sie einfach in das entsprechende Wort den Wert
-1 (0xFFFF, Wortlänge) hinein (Andere Werte werden ignoriert und bei der
nächsten Gelegenheit wieder auf 0 gesetzt). Fortan werden folgende GEMDOS-
Zugriffe darauf mit einem EACCDN-Fehler (ACCESS DENIED, -36) quittiert:

    Dcreate(), Ddelete(), Fcreate(), Fopen(), Fdelete(), Fattrib(),
    Fsfirst(), Frename()

Dies passiert solange, bis Sie wieder eine 0 in den entsprechenden Eintrag
schreiben, was Sie deshalb natürlich nicht vergessen dürfen! Wenn Sie
selbst dort bereits einen negativen Wert vorfinden, so dürfen Sie ebenfalls
nicht auf dem entsprechenden Laufwerk operieren (außer eventuell für
Lesezugriffe), da ein anderes Programm offensichtlich ebenfalls gerade die
Daten modifiziert und Ihnen zuvor gekommen ist, die Zugriffsrechte zu
ergattern.

Beachten Sie, daß Sie den Test auf Zugriffsmöglichkeit via BIOS noch _vor_
einem Getbpb()-Aufruf durchführen müssen. Danach haben Sie dem GEMDOS schon
eine eventuell aufgelaufene Medienwechsel-Meldung vor der Nase
weggeschnappt und kommen um ein 'Force-Media-Change' nicht mehr herum.


Hilfsprogramme
==============

Während der Programmentwicklung mögen Ihnen die Tool OFLSSHOW.ACC und
OPN_FILE.ACC (oder auch jeweils auch als *.PRG nutzbar, dann aber weniger
nützlich...) hilfreich sein.


OFLSSHOW.ACC:
-------------
...liest den Cookie aus und zeigt Ihnen für die Laufwerke A: bis Z: an,
wieviele Dateien in diesem Moment darauf geöffnet sind (es zeigt nichts -
also nicht etwa '0' - an, wenn keine geöffnet sind, weil mir dies
übersichtlicher erschien!). Weiterhin ist das gerade aktuelle Laufwerk
(Default-Drive des aktuellen Prozesses) invertiert und es wird die Produkt-
Kennung und Versionsnummer aus der OFLS-Struktur angezeigt. Bei Änderungen
wird das Anzeigefeld automatisch bis zu zweimal pro Sekunde erneuert, so
daß Sie Veränderungen auch beobachten können, wenn OFLSSHOW selbst gerade
nicht das oberste Fenster ist.

Wenn Ihr Programm (oder ein anderes CHK_OFLS-modifiziertes Tool) das
GEMDOS auf einer Partition sperrt, so wird dies durch eine unterbrochene
Linie ('-X-') angezeigt. Auf diesem Laufwerk sind nun keine der o.g. GEMDOS-
Zugriffe möglich. Steht ein negativer Wert kleiner -1 in einem Eintrag,
wird dies durch '???' gekennzeichnet.


OPN_FILE.ACC
------------
...dient lediglich dazu, offene Dateien zu produzieren. Dies ist nützlich,
um beim eigenen Programm das Zusammenspiel mit CHK_OFLS zu testen, da es
ansonsten in der Regel schwierig ist, ein Programm mit offenen Dateien auf
dem gewünschten Laufwerk zum richtigen Zeitpunkt ausfindig zu machen.

Man wählt zunächst das gewünschte Laufwerk an und kann durch Klick auf
'Datei öffnen' eine oder durch wiederholtes Klicken mehrere Dateien öffnen.
Dabei läßt sich der Modus vorwählen, in dem die Datei geöffnet wird.
Zunächst wird sie immer per 'Fcreate' angelegt, bei 'Read' oder 'Write'
jedoch gleich wieder geschlossen und im entsprechenden Modus erneut
geöffnet.

Die Anzahl der offenen Dateien wird unterhalb des Laufwerksbuchstaben
mitprotokolliert. Die angelegten Dateien heißen 'TEST.XXX', wobei XXX die
laufende Nummer der dort geöffneten Files ist. 'Schließen und löschen'
macht eben dieses in umgekehrter Reihenfolge auf dem gerade angewählten
Laufwerk.

Wenn man aus einem Programm heraus Dateien öffnet, diese nicht schließt
aber das Programm verläßt, so werden die Dateien zwangsweise vom
Betriebssystem geschlossen. Während CHK_OFLS dies durchaus richtig
mitprotokolliert, ist für OPN_FILE die Arbeit zuende, daher stehen die
angelegten 'TEST.XXX'-Dateien noch auf dem entsprechenden Laufwerk. Diese
müssen dann noch von Hand wieder gelöscht werden.

Wenn man durch einen forcierten Medienwechsel (z.B. 'ESC' im Desktop bei
Anzeige des Laufwerks mit den just offenen Dateien) die Dateien zwangsweise
schließt, so bemerkt dies OPN_FILE nicht (im ggs. zu CHK_OFLS). Per
'Schließen und löschen' wird die als offen angezeigte Anzahl von Dateien
aber dennoch wieder entfernt, lediglich die Freigabe der Dateihandle
mißlingt, wovon Sie aber nichts bemerken.



'Technische' Daten:
===================

Trap#1 (GEMDOS) XBRA: 'OFLS'
TRAP#13 (BIOS) XBRA: 'OFLS'
Cookie-Kennung: 'OFLS'

XBRA für Cookie-Reset-Routine bei TOS <= 1.04: 'OFLS'

CHK_OFLS legt - falls erforderlich (TOS <= 1.04 ohne bereits inst.
Cookies) - einen neuen Cookie-Jar inkl. Reset-Routine an bzw. vergrößert
ihn nötigenfalls um 20 neue Cookies.

CHK_OFLS ist ab Version 1.02 vollständig reentrant, so daß auch dem Einsatz
unter MiNT nichts im Wege steht. Für MultiTos ist der Einsatz nicht
sinnvoll, da die Dateihandles nicht mehr global, sondern prozessweise
vergeben werden. In MultiTos und ab MiNT 0.94 hat man aber ohnehin die
Möglichkeit, die Betriebssystemroutine 'Dlock()' zum verriegeln eines
Laufwerkes zu benutzen.